Serialization is a mechanism for taking a data structure (e.g., a graph of objects, a call stack) and converting it to a stream of data in a particular external format. At deserialization, the stream of data is converted back into the data structure with the same topology of the original data structure. Serialization facilitates inter-process communication such as transmissions between address spaces, or persistence such as storage on a non-volatile media. For example, an executable program can be serialized at a server end and transferred over to an application running on a client end for executing the executable program at the client. Additionally, an object can be serialized and stored in contiguous memory to save space. Inter-process communications and object persistence are fundamental techniques used in many software applications. The main use of a serialization stream is for saving a graph of objects externally in a file or transferring the serialization data by remoting between computer process or processors.
A serialization stream externalizes the internal description of a graph of objects. The external description will vary depending on its uses. HTML and XML formats provide easy to read formats, which are widely used in interoperation between different systems. Binary formats are used for the efficient transfer of data. Typically, the formats that are used are selected for standards or computation reasons. Conventional distributed object systems may have built-in support for the operations involved in serialization and deserialization of data structures. Serialization is a standard part of many object frameworks. However, the format in which the serialization stream has been externalized is fixed according to the framework being utilized. Furthermore, conventional formats are not selectable, customizable or pluggable.
Serialization is typically performed by a formatter. Serialization involves writing the state information of parameters and/or objects to a stream that may be read by a formatter on a server, so that the parameters and/or objects can be recreated on the server side. Similarly, serialization involves writing the state information of return parameters and/or objects to a stream that may be read by a formatter on the client, so that the return parameters and/or objects can be recreated back on the client side. Formatters also typically perform the inverse operation of deserialization. The formatters dictate the format in which the parameters and/or objects and their associated state are written to the stream. For example, a first formatter may employ a binary format while a second formatter may employ an XML format to represent the types of the parameters and/or objects and their associated state. Conventionally, formatters are not selectable, pluggable or customizable and thus conventional systems suffer from problems associated with inflexibility (e.g., inability to interact with new externalized formats).
Conventional distributed object systems may have built-in support for the operations involved in parameter marshalling, which is the packaging of the parameters (call and return) of method calls made on remote objects. Typically, such built-in parameter marshalling is not customizable. In distributed object systems, a user application typically has a local representative or proxy to a remote object, where the remote object is often referred to as the server and/or server object. The distributed object system infrastructure typically intercepts method calls made on the proxy, and, in collaboration with infrastructure code delivers the call and parameters associated with the call from the proxy to the server. Similarly, results of the invocation of the call on the server are propagated by the infrastructure from the server back to the proxy, so that to the user it appears that the call executed locally. Thus, processing involved in remoting a call made on a proxy includes serializing parameters (which may reference objects holding state on the client) associated with the method call.
Conventional serialization and deserialization architectures do not provide for remoting that is pluggable, customizable or selectable. Custom routines are employed to provide remoting between a server and a client. A developer or user must conform to these customized routines to allow for remoting of their respective applications. Additionally, conventional serialization and deserialization architectures do not provide mechanisms for dealing with special circumstances, such as a one instance per process situation. Again, custom routines must be adhered to serialize and deserialize graphs of object containing such object types.
Thus, there remains an unmet need for a system and method that mitigates inflexibility problems associated with conventional serialization and deserialization architectures.